1. Field of the Invention
The invention relates to recovery of protocol errors in GTP-u.
2. Description of the Related Art
A tunneling protocol is a network protocol which encapsulates a payload protocol, while acting as a payload protocol. A tunneling protocol may be used for various reasons, including carrying a payload over an incompatible delivery network, or to provide a secure path through an untrusted network.
A typical user plane data traffic tunneling mechanism involves three phases: constructing the tunnel, maintaining the tunnel and gracefully bringing the tunnel down. Normally there are two network nodes involved—the tunnel endpoints.
Construction of a tunnel usually involves an exchange of client data between the tunnel endpoints. The tunnel endpoints may be constructed by, for example, network gateways. Both of the network gateways involved in building the tunnel need to create a data entity for maintaining the tunnel. This entity, which is known as a PDP Context in GPRS Tunneling Protocol (GTP), contains information about, for example, user mobility, charging, authentication, Quality of Service, etc. Each user plane data packet that arrives through the tunnel into the tunnel endpoint node needs to be associated with one such entity. Each tunnel protocol packet contains an identifier, called a Tunnel Endpoint Identifier (TEID) to make that possible. The TEID helps the tunnel endpoint node detect the correct User Entity associated with the stream of data packets belonging to one particular user.
One network tunnel endpoint node may hold millions of tunnel endpoints at any given time. Every incoming user plane data packet needs to be quickly associated with a correct User Entity. To that end, tunneling protocols often involve a tunneling initialization stage in which each of the tunnel endpoint nodes allocate an identifier for each user traffic stream. Each of the tunnel endpoint nodes then instructs the other endpoint node to include that identifier in every data packet related to a particular user plane data packet stream.
The composition of the TEID may be implementation specific. The TEID may be comprised of, for example, a processing blade number or a position of a User Entity in a table of User Entities. As shown in FIG. 1, for example, user k, which is in position 2 (reference 20) of a User Entities Database (DB) 16 at Node A (reference 12), is assigned a TEID of 2 (reference 18) by Node A (reference 12). At Node B (reference 14), on the other hand, user k is assigned a TEID equal to its processing plate number, or 1001(hex) (reference 24), by Node B (reference 14).
An identifier allocated to a traffic stream by one of the network nodes is just an arbitrary number to the other network node. If each of the tunnel end nodes includes the identifier allocated by the tunnel end node in each and every data packet, however, both of the tunnel end nodes will be able to associate a user plane packet with its owner quickly.
As shown in FIG. 2, for example, Node A (reference 12) stores the TEID of 1001(hex) (reference 28) assigned to user k by Node B (reference 14). Node B (reference 14), similarly, stores the TEID of 2 (reference 30) assigned to the user k by Node A (reference 12). The User Plane Packet (reference 32) sent by Node A (reference 12) to Node B (reference 14) may be seen to include the TEID of 1001(hex), which was assigned to user k by Node B (reference 14). Consequently, when the User Plane Packet 32 reaches Node B (reference 14), Node B (reference 14) will be able to associate the User Plane Packet 32 with user k quickly and easily.
Maintenance of a tunnel throughout its existence involves constantly verifying that each tunnel endpoint node is up and running. If either of the tunnel endpoint nodes loses the contents of its User Entity database due to, for example software or hardware malfunction, the other tunnel endpoint node must react by removing all the user plane data tunnel endpoints associated with the broken tunnel endpoint node.
Graceful termination of a user plane data tunnel involves an exchange of control messaging initiated by either tunnel endpoint node informing the other tunnel endpoint node that the tunnel is going down. Each tunnel endpoint node will then remove the User Entity from its database and refuse to forward any data packets associated with the terminated tunnel to the other tunnel endpoint node.
A problem arises if there is a disruption in the maintenance protocol of the user plane data tunnel. If one tunnel endpoint node, let's say Node A, removes—or loses—a User Entity database entry but the information of that happening doesn't reach the other one, Node B, Node B may still keep forwarding packets associated with a lost user (let's say user k) to Node A, providing each packet with the Tunnel Endpoint Identifier once allocated by Node A for the user k, i.e. (TEIDk[A]).
Tunnel Endpoint Node A, now having lost user k from its database, recognizes a problem in the tunnel protocol and informs Node B about the failure. Node A notifies Node B by sending an error message—known as Error Indication in GTP-u protocol—to Node B informing Node B of a protocol problem related to the tunnel endpoint identifier TEIDk[A]. When Node B receives the Error Indication, Node B should remove the User Entity it still has involving the User k. However, Node B has no direct mapping of TEIDk[A] to the User Entity Database entry being affected. So far it has relied on Node A using TEIDk[B] in all communication involving user k, but Node A has lost that identifier along with all other information about user k.
A User Entity database Entry contains among other things the address of the other endpoint of the tunnel and the Tunnel Endpoint Identifier the other peer has allocated a particular user. Now having received an Error Indication message from one tunnel endpoint node in address A, Node B can scan through its User Entity database for an entry with a combination of tunnel endpoint node address A/tunnel endpoint identifier TEIDk[A]. This is a linear search and can be fairly time consuming.
As a performance remedy the tunnel endpoint node may maintain a search tree or a hash table in which the key would be a tuple of a tunnel endpoint node address and the remotely allocated TEID. This search structure, however, may become very large and if not carefully maintained may become corrupted over time. Furthermore, there is no inherent self-fixing mechanism for this search structure.